1. Field of the Invention
The present invention relates to software systems that use diverse operations including transactions and messages and, more particularly, to a method and system to group these operations.
2. Description of Prior Art
Software engineering for enterprise-scale systems presents some important challenges. These include the need to integrate diverse software components in a distributed, heterogeneous system environment while ensuring properties such as reliability, salability, evolvability, etc. In recent years, a category of software commonly referred to as middleware has emerged to address these needs. Middleware is connectivity software that defines a standard for different software components to interoperate with each other. Middleware provides basic communication mechanisms between components while hiding any complexities introduced through distribution and heterogeneity of the components. In addition, middleware provides higher-level services to facilitate application software development and to address software quality concerns.
Two principle kinds of middleware are object-oriented middleware (OOM) and message-oriented middleware (MOM), both contribute to the development of reliable software systems. OOM, for example, provides support for software reliability through distributed transactions. Alternatively, MOM provides support for reliable asynchronous communication between distributed components. Both OOM and MOM have evolved individually and independently over the past years, and they have been implemented in the development of many enterprise software systems.
The integration and interoperation of services becomes a concern when using OOM and MOM in the same system. In particular, while transactions and messages are reliable individually, existing middleware does not directly support an equivalent level of reliability for use of OOM and MOM in combination.
OOM can be exemplified by object request brokers (ORB), for example, the Object Management Group's Common Object Request Broker Architecture (CORBA) and component technology (e.g., Sun's Enterprise JavaBeans (EJB)). The software components to be integrated are rendered as distributed objects that offer well-defined interfaces. A synchronous client/server model is the standard communications model between objects.
MOM can be exemplified by message queuing (MQ) systems, for example, IBM's MQSeries and implementations of the Java Message Service (JMS) application program interface. Components integrated by MOM communicate by means of asynchronous message exchange, for example, with message queues as intermediators. Components read or write messages (data) using queues, and the distribution of the messages through the network is the responsibility of the MOM. Thus, the components do not directly interact with each other. Communicating components may be anonymous to each other and are typically decoupled.
Each type of middleware has particular advantages. The object-oriented model of OOM is consistent with the object paradigm commonly followed in modem system development and thus helps to support consistent development processes. OOM further aims to promote extensibility and reusability by strictly separating the interfaces and implementations of a component. On the other hand, MOM is particularly well-suited in cases where a decoupling in time or space is needed or desired. In addition, a multiplicity of communication partners can be supported through multicast notification using MOM. Consequently, OOM and MOM are often used in combination. For example, message queuing may be used to communicate with legacy backend servers, while distributed object calls may be used to communicate with web frontends.
One important approach to software reliability is the use of transactions. OOM object transactions resemble database transactions: a transaction transforms a shared state of a system from one consistent state to another consistent state based on an all-or-nothing execution model. The actions that constitute a transaction are synchronous requests on objects. Support for transaction processing has been successfully introduced with services like the CORBA Object Transaction Service (OTS), and its Java binding JTS and the Java Transaction API (JTA).
MOM also has a notion of transaction. However, MOM transactions are different from OOM transactions. A transaction in MOM refers to the grouping of a set of produced or consumed messages as one atomic unit of work: either all messages that constitute a MOM transaction are sent out and read, or none of the messages are sent out and read.
Referring to FIG. 1, a software system using transactions and messages is shown. The system includes a component 110 including both a transactional client and a messaging component. The system also includes a transactional resource 120 and a messaging component 130. Component 110 performs synchronous invocations on the transactional resource 120 within a transaction context. Independent of this transaction context, component 110 communicates asynchronously with the messaging component 130. The system depicted in FIG. 1 is a system illustrating a software system architecture common to existing transaction and messaging systems. A transaction involving one or more transactional resources is independent of any message exchanged between one or more messaging components. Component 110 uses transactions and messaging in an uncoupled way. Therefore, no properties are observed for the operations as a group.
Existing approaches to grouping operations into larger units to ensure certain properties are limited in that support is only provided for grouping of operations of a homogeneous kind. For example, database or object transactions only support the grouping of synchronous requests on transactional resources. Alternatively, messaging units of work only support the grouping of messages. Thus, operations of a heterogeneous kind are not dependent on each other in a group.
There is no known support for grouping diverse operations. As a consequence, software architects need to separate transactions and messages. Therefore a need exists for a system and method for integrating distribution object transaction processing and asynchronous messaging by grouping diverse operations.